Systems and methods for controlling data paths for wireless networks

ABSTRACT

A network node for use in a wireless sensor network has memory that is configured to store a routing indicator indicating whether the network node may function as a routing node for messages destined for other nodes of the wireless sensor network. The network node also has logic that is configured to control, based on the routing indicator, whether the network node is specified as a hop for a data path from a source node to a destination node of the wireless sensor network. In one exemplary embodiment, the routing indicator is controlled based on sleeping characteristics of the network node.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/099,453, entitled “Systems and Methods for Controlling WirelessSensor Networks,” and filed on Sep. 23, 2008, which is incorporatedherein by reference. This application also claims priority to U.S.Provisional Patent Application No. 61/105,692, entitled “Systems andMethods for Controlling Wireless Sensor Networks,” and filed on Oct. 15,2008, which is incorporated herein by reference. This application claimspriority to U.S. Provisional Patent Application No. 61/107,213, entitled“Systems and Methods for Controlling Wireless Networks,” and filed onOct. 21, 2008, which is incorporated herein by reference.

RELATED ART

The proliferation of applications using wireless communication isincreasing as more and more users seek solutions that provide increasedmobility and flexibility. However, wireless communication has numerouschallenges and problems. For example, since wireless signals aretransmitted through free space, data collisions with other wirelesssignals from foreign networks can occur. Further, the effects of variousnoise sources and even weather can have a more pronounced effect onwireless communication as compared to communication occurring overphysical media. Moreover, wireless communication in particularly noisyenvironments, such as manufacturing plants, can be quite problematic.

Further, in implementing a wireless network, such as a Wireless SensorNetwork (WSN), various protocols need to be established and techniquesfor overcoming some of the aforementioned challenges for wirelesscommunication are necessary. In addition, the functionality andinteraction of the nodes of the network can be relatively complex,particularly for wireless networks in which data communication may beunreliable at times due to varying environmental conditions and noiselevels. Moreover, engineering a wireless sensor network can be extremelyexpensive and burdensome.

Techniques for reducing the cost and burden of designing and developingnetworks, such as wireless sensor networks, are generally desired.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure can be better understood with reference to the followingdrawings. The elements of the drawings are not necessarily to scalerelative to each other, emphasis instead being placed upon clearlyillustrating the principles of the disclosure. Furthermore, likereference numerals designate corresponding parts throughout the severalviews.

FIG. 1 is a block diagram illustrating an exemplary wireless network inaccordance with the present disclosure.

FIG. 2 is a block diagram illustrating an exemplary network node, suchas is depicted in FIG. 1.

FIG. 3 is a block diagram illustrating an exemplary wireless network inaccordance with the present disclosure.

FIG. 4 is a block diagram illustrating an exemplary host, such as isdepicted in FIG. 3.

FIG. 5 is a block diagram illustrating an exemplary wireless network inaccordance with the present disclosure.

FIG. 6 is a diagram illustrating an exemplary graphical user interface(GUI) for displaying information about the configuration of a network,such as is depicted in FIG. 3.

FIG. 7 is a diagram illustrating an exemplary GUI for displayinginformation about the configuration of a network, such as is depicted inFIG. 3.

FIG. 8 is diagram illustrating an exemplary GUI for displaying sourcecode for nodes of a network, such as is depicted by FIG. 3.

FIG. 9 is a block diagram illustrating an exemplary wireless network inaccordance with the present disclosure.

FIG. 10 is a flow chart illustrating an exemplary method for respondingto a route discovery message.

FIG. 11 is a block diagram illustrating an exemplary network node, suchas is depicted in FIG. 1.

DETAILED DESCRIPTION

The present disclosure generally pertains to systems and methods forcontrolling wireless networks. In one exemplary embodiment of thepresent disclosure, a wireless network has a plurality of nodes. Thenodes have predefined functions and a network stack that allowcommunication among the nodes and that allow the network to performbasic functions, such as a pushing tokenized scripts from one node toanother. Thus, by writing scripts and uploading the scripts to variousnodes, as may be desired, a user of the network is able to dynamicallyconfigure the nodes to perform any desired function for an intendedapplication without having to implement and debug a design for thewireless communication among the nodes. Indeed, it is unnecessary forthe user to have any knowledge of the underlying communicationoperations that transport data among the nodes. By eliminating the needof the user to design a wireless communication solution for his intendedapplication and subsequent changes to his intended application, theprocess of implementing a wireless network and changing its behaviorover time is greatly simplified.

In one exemplary embodiment, each node of the network has a networkstack and a virtual machine. The network stack is configured topacketize messages for communication across the network. The messagesmay include scripts capable of running on the virtual machine of anynode. Thus, in implementing a wireless network, a user may define ascript for performing a desired function and push the script from onenode to another node such that the receiving node is able to execute thescript to perform the desired function. Further, the network stackswithin the network handle the communication of the script through thenetwork such that it is unnecessary for the user pushing the script overthe network to have any knowledge of the underlying communicationoperations that transport the script from one node to the next. Thus,the user is able to dynamically change the behavior of any node withinthe network by simply writing a script and submitting a request for thescript to be uploaded to a desired node. The process of communicatingthe script to the node through the network and implementing the functionon the desired node is transparent to the user.

FIG. 1 depicts a wireless sensor network 20 of an exemplary embodimentof the present disclosure. The network 20 has a plurality of nodes21-24. FIG. 1 depicts four nodes 21-24 for simplicity, but the network20 may have any number of nodes 21-24 in other embodiments. In oneexemplary embodiment, the network 20 is implemented as a mesh network,but other types of networks may be implemented in other embodiments.Exemplary networks are described in U.S. patent application Ser. No.12/114,566, entitled “Systems and Methods for Dynamically ConfiguringNode Behavior in a Sensor Network, and filed on May 2, 2008, which isincorporated herein by reference, and in U.S. Provisional PatentApplication No. 60/974,836, entitled “Wireless Communication Networks,”and filed on Sep. 24, 2007, which is incorporated herein by reference.Exemplary networks are further described in U.S. patent application Ser.No. 12/237,158, entitled “Systems and Methods for Adaptively AdjustingCodec Rates for Communication Networks,” and filed on Sep. 24, 2008,which is incorporated herein by reference, and in U.S. patentapplication Ser. No. 12/237,192, entitled “Systems and Methods forReducing Data Collisions in Wireless Network Communications,” and filedon Sep. 24, 2008, which is incorporated herein by reference.

Each node 21-24 is able to communicate with any of the other nodes21-24. In one exemplary embodiment, the nodes 21-24 communicate amongone another wirelessly, but it is possible for any of the nodes 21-24 tocommunicate with any of the other nodes 21-24 over a conductive medium.Messages may hop from node-to-node in order to reach a destination. Forexample, in the exemplary embodiment shown by FIG. 1, the nodes 21-23are within range of each other such that any of the nodes 21-23 cancommunicate directly with any of the other nodes 21-23. However, thenode 24 is only within range of node 23. The other nodes 21 and 22 canuse node 23 to route a message to node 24. In this regard, each node21-24 has a routing table that indicates routes for messages. As knownin the art, routing tables can be created and updated via a variety oftechniques. In general, nodes communicate among one another to learn ofdata paths for various destinations. Once a path to a particulardestination is discovered, the routing table or tables of the nodesalong the path may be updated and later used to route a message to thedestination.

Moreover, to enable the node 21 of network 20 to send a message to node24, the node 21 may have a routing table indicating that such a messageis to hop through the node 23. Thus, the node 21 inserts the address,referred to as the “hop address,” of the next hop or, in other words,the next node to receive the message (i.e., node 23 in this example), aswell as the address, referred to as the “destination address,” of thenode (i.e., node 24 in this example) to ultimately receive and processthe message. Based on the hop address, the routing node 23 receives themessage and consults its routing table to determine where to route themessage. In the instant example, the routing table indicates that amessage destined for the node 24 can be transmitted directly to the node24. Thus, the routing node 23 retransmits the message using the addressof the node 24 as both the destination address and the hop address forthe message. The node 24 receives the message and processes asappropriate. Thus, even though node 21 cannot communicate directly withthe node 24, the node 21 can have the message routed through the network20 to the node 24. The concept of routing messages through a meshnetwork using routing tables is generally well-known.

In general, there are at least two types of messages communicated by thenetwork 20, unicast messages and multicast messages. A “unicast” messagerefers to a message that is destined for a specific node, referred to asthe “destination” or “destination node.” Such a message includes adestination address identifying the destination node. In general, a nodein the network 20 does not respond to a unicast message unless the nodeis identified by either the destination address or a hop address in themessage. Thus, if a node is not the destination node for a unicastmessage or within the data path for routing the message to itsdestination, the node does not respond to the unicast message but ratherdiscards it upon reception.

In one exemplary embodiment, reliability of data communication isenhanced through the use of acknowledgements. That is, when a node(“receiving node”) receives a unicast message transmitted from anothernode (“transmitting node”), the receiving node replies with anacknowledgment to the transmitting node. Thus, upon receipt of theacknowledgement, the transmitting node is aware that the unicast messagehas been received by the receiving node. If the transmitting node doesnot receive an acknowledgment within a predefined time period aftertransmission, then the transmitting node assumes that the unicastmessage failed to reach the receiving node and retransmits the unicastmessage. Note that each message includes the address of the transmittingnode. In addition, an acknowledgement is sent for each respective hopalong a data path.

Thus, each node along the data path is able to ensure that the next hophas received the unicast message.

A “multicast” message, on the other hand, is a message destined formultiple nodes. In many cases, it is intended for a multicast message tobe received and processed by every node in the network 24. Multicastmessages are not communicated along predefined data paths indicated bythe routing tables of the network nodes, and acknowledgments are notreturned for multicast messages. Instead, a multicast message isgenerally rebroadcast by nodes that receive it regardless of whethersuch nodes are identified by the message.

In one exemplary embodiment, each multicast message includes a value,referred to as a “time-to-live value,” indicating the number of timesthat the message is to be retransmitted. Each node that receives amulticast message is configured to retransmit the message as long as thetime-to-live value is above a threshold, such as zero. However, beforeretransmitting the multicast message, the node decrements thetime-to-live value. Thus, eventually, a node receives the multicastmessage after the time-to-live value has been decremented below thethreshold and, therefore, does not retransmit the message. Accordingly,depending on the time-to-live value, a multicast message is rebroadcastthrough the network 20 for a limited time. Note that the same multicastmessage may be received by multiple nodes and retransmitted by each suchnode. Thus, after transmission of a multicast message, the message isrepeatedly transmitted by other nodes through the network 20 for afinite period of time. In one exemplary embodiment, acknowledgments arenot communicated for multicast messages, although the communication ofacknowledgments is possible, if desired. Instead, it is assumed thateach node of the network 20 has received the multicast message.

As an example, assume that a significant number of data collisions occuras the nodes are attempting communication on a particular channel. Oneof the nodes, sensing a high number of data collisions, may determinethat communication is to be switched to a new channel. In such anexample, the node may transmit a multicast message instructing the othernodes to switch to the new channel. Each node that receives themulticast message retransmits the message and begins communicating overthe new channel as instructed. Eventually, the multicast message isreceived by each node of the network 20, and each such node, therefore,begins to communicate over the new channel. In other examples, othertypes of multicast messages may be communicated.

FIG. 2 depicts an exemplary embodiment of one of the nodes 24. Note thatany of the other nodes 21-23 may be configured similarly to or identicalto the node 24 depicted by FIG. 2. In the exemplary embodiment shown byFIG. 2, various software, including core functions 51, a script image52, a virtual machine 53, and a network stack 54, are stored in memory55. In other embodiments, portions of the components 51-54 may beimplemented in firmware, hardware, or a combination of software,firmware, and/or hardware. Further, various data, such as a functioncatalog 61 and configuration parameters 63 are also stored in memory 55,and a portion of the memory 55 is used as a packet buffer 65 to bufferpackets that have been communicated through the network 20 and receivedby the node 24.

Note that the core functions 51, the script image 52, the virtualmachine 53, and the network stack 54, when implemented in software, canbe stored and transported on any computer-readable medium for use by orin connection with an instruction execution apparatus that can fetch andexecute instructions. In the context of this document, a“computer-readable medium” can be any means that can contain or storecode for use by or in connection with the instruction executionapparatus.

The exemplary embodiment of the network node 24 depicted by FIG. 2includes a processing element 72, which comprises processing hardwarefor executing instructions stored in memory 55. The processing element72 communicates to and drives the other elements within the node 24 viaa local interface 75, which can include at least one bus. Furthermore, acommunication device 77 communicates with other nodes of the network 20.In one exemplary embodiment, the communication device 77 comprises an RFradio or other wireless communication device for communicating wirelesssignals with other nodes of the network 20.

The node 24 also has an input/output (I/O) interface 78 for enabling thenode 24 to exchange data with other devices. For example, the I/Ointerface 78 may be coupled to a sensor (not shown) and receive datafrom the sensor. The I/O interface 78 may also be coupled to anapparatus (not shown), such as a motor or actuator, for performing anaction under the direction and control of the script image 52 or otherlogic.

The node 24 is coupled to a power supply 79, which provides electricalpower to the components of the node 24. In one exemplary embodiment, thepower supply 79 comprises a battery. However, the power supply 79 mayhave an interface that allows the power supply 79 to plug into orotherwise interface with an external component, such as a wall outlet,and receive electrical power from such external component.

In one exemplary embodiment, each component shown by FIG. 2 resides onand is integrated with a printed circuit board (PCB) 81. However, inother embodiments, other arrangements of the node 24 are possible.

The stack 54 is configured to drive the communication device 77 and tohandle network communication for the node 24. In this regard, whenpayload data is to be transmitted through the network 20, the networkstack 54 is configured to packetize the payload data into at least onedata packet and to wirelessly transmit the data packet from the node 24via the communication device 77. When a data packet is received by thecommunication device 77, the packet is buffered in the packet buffer 65,and the stack 54 depacketizes the packet in order to recover the payloaddata. The network stack 54 is also configured to retransmit multicastmessages and to ensure the reliable communication of unicast messages.In this regard, the stack 54 is configured to transmit acknowledgements,as appropriate, for received messages, and to ensure thatacknowledgements are received for transmitted messages. If anacknowledgment is not received for a transmitted message in a timelymanner, the network stack 54 is configured to initiate a retransmissionof the message. Moreover, the operation of the stack 54 is transparentto the script image 52.

For example, once the script image 52, which is running on the virtualmachine 53, provides data to be transmitted to another node, the scriptimage 52 can proceed with another task without handling or monitoringany part of the communication operations that are performed in order toreliably communicate the data to its destination. Moreover, theprogrammer of the script image 52 does not need to program the scriptimage 52 to handle or monitor such communication operations.

In one exemplary embodiment, the virtual machine 53 is implemented as abytecode interpreter. In this regard, the script image 52 comprisebytecode capable of being executed by the virtual machine 53. In oneembodiment, the core functions 51 are written in the C computerlanguage, and the script image 52 is written in the Python computerlanguage. However, other languages are possible in other embodiments.

Further, in one exemplary embodiment, the script image 52 is written bya user and uploaded to the node 24 over the network 20, as will bedescribed in more detail hereafter.

Each script image 52 includes at least one function having a functionname that enables the function to be called by a function call, alsoreferred to herein as a “procedure call.” The script image 52 isuser-defined and can be written to perform any desired functionality,such as monitoring or controlling devices external to the node 24,depending on the node's intended application.

The node 24 also has a plurality of predefined functions 51, referred toas the “core functions.” Each core function 51 is associated with afunction name that enables the function to be called by a function call.The core functions 51 enable a basic set of functionality that is likelyto be useful regardless of the intended application of the node 24. Forexample, one of the core functions 51 may enable data to be written toor read from the memory 55. In another example, a core function 51 isused to store the script image 52 into memory 55. In another example, acore function 51 is used to set one or more of the configurationparameters 63. As will be described in more detail hereafter, theconfiguration parameters 63 are settings that control various aspects ofthe node's operation. Such configuration parameters 63 may be checked bythe stack 54 or other node resources at run time to control variousoperations. Various other types of functionality may be performed by thecore functions 51.

The name of each function, inclusive of the core functions 51 and thefunctions defined by the script image 52, is listed in a functioncatalog 61. The function catalog 61 comprises a listing of functionnames, and for each function name, the catalog 61 comprises a pointerthat points to the address where the function is stored. Thus, when thevirtual machine 53 executes a function call, the virtual machine 53searches the function catalog 61 to find the matching function name.Once the matching name is found in the catalog 61, the associatedpointer is used by the virtual machine 53 to locate and invoke thecalled function.

In one exemplary embodiment, the function catalog 61 is pre-sorted intosome logical order so that it is unnecessary for the virtual machine 53to check each function name in the catalog 61 before making adetermination that a given function name is missing from the catalog 61.For example, in one exemplary embodiment, the function names in thecatalog 61 are listed in alphabetical order. Thus, when the virtualmachine 53 executes a function call, the virtual machine 53 implementsan algorithm that efficiently finds, without checking every name in thecatalog 61, the two function names in the catalog 61 that wouldimmediately precede and follow the function name indicated by thefunction call. If the called function name is not between the locatedfunction names in the catalog 61, then the virtual machine 53 determinesthat the called function is not stored in the memory 55 and proceedsaccordingly without checking the names of other functions in the catalog61. If the called function name is between the located function names inthe catalog 61, then the virtual machine 53 retrieves and executes thecalled function based on the associated pointer in the catalog 61. Inother embodiments, the function catalog 61 can be pre-sorted indifferent ways, and it is unnecessary for the function catalog 61 to bepre-sorted in every embodiment. Pre-sorting the function catalog 61,however, can save processing time in finding a called function.

As shown by FIG. 2, the node 24 comprises core logic 80 for generallycontrolling the resources of the node 24. In one exemplary embodiment,the core logic 80 is firmware that runs on the processing element 72independent of the virtual machine 53. However, other configurations ofthe core logic 80 are possible. For example, the core logic 80 can beimplemented in hardware, software, firmware, or any combination thereof.The core logic 80 performs various basic control functions, such asinterfacing data from the script image 52 or core functions 51 withhardware resources, such as the communication device 77 and/or I/Ointerface 78. Various other functionality may be performed by the corelogic 80, which will be described in more detail hereafter.

In one exemplary embodiment, a virtual machine 53 is stored in each nodeof the network 20 so that any given script image 52 may be successfullyexecuted on any node of the network 20, if desired. Exemplary techniquesfor defining the script images 52 and communicating the script images 52through the network 20 will be described in more detail hereafter.

Note that running the script image 52 on a virtual machine 53 helps toisolate the script image 52 from the stack 54 such that the programmerof the script image 52 does not need to be concerned with how the stack54 operates or when resources are consumed by the stack 54. Further, inone exemplary embodiment, various hardware resources allocated to thevirtual machine 53 are not allocated to the stack 54 so that operationof the stack 54 can be separated from that of the virtual machine 53.For example, assume that the processing element 72 has multiple timers(not shown). Some of the timers are exclusively allocated to the virtualmachine 53 relative to the stack 54 so that the stack 54 may not usethese timers, and some of the timers are exclusively allocated to thestack 54 relative to the virtual machine 53 so that the virtual machine53 may not use these timers. Various other hardware resources may beexclusively allocated to the stack 54 or virtual machine 53 in a similarmanner. In utilizing the resources allocated to the virtual machine 53,it is unnecessary for the programmer of a script image 52, which runs onthe virtual machine 53, to be concerned with the operation of the stack54 since the stack 54 cannot consume such resources.

Thus, the programmer may write the script image 52 to perform anydesired function without having knowledge of how the stack 54 handlescommunication with the network 20. Further, one of the core functions 51may be to interface payload data with the stack 54 such that the stack54 communicates the payload data through the network 20 to adestination. In such case, the programmer may simply include a functioncall for such function in the script image 52 being written and assumethat the payload data will be successfully communicated upon executionof the function call without writing any code for handling or monitoringsuch communication. In this regard, the underlying operations forcommunicating the payload data over the network 20 are transparent tothe script image 52 and, therefore, the programmer who is writing thescript image 52.

Indeed, in one exemplary embodiment, a manufacturer of the network 20provides a user (e.g., a purchaser) with all of the nodes 21-24. Foreach node 21-24, the components of the node reside on a PCB 81 that issmall enough to be transported by hand to any desired location. Further,each node is supplied to the user with all of the components shown byFIG. 2 except for the script image 52, which is later written by theuser and uploaded to the nodes 21-24 as appropriate depending on theintended application for the network 20. However, the core functions 51,the virtual machine 53, and the stack 54 provide the user with theability to easily upload the script image 52 into any node without anyunderstanding of how the stack 54 handles wireless communication overthe network 20. Further, the configuration parameters 63 are set tocertain default values and wireless communication is enabled at power upwithout the user having to upload any code into any of the node 21-24.Thus, the user may connect any of the nodes 21-24 to any apparatus to becontrolled via the network 20 and/or any sensor to be monitored by thenetwork 20. The user may also use the network 20 to wirelessly push thescripts 52 for controlling any such apparatus or monitoring any suchsensor to any of the nodes 21-24 as may be desired. In this regard,without having any knowledge of the underlying communication enabled bythe stack 54, the user can dynamically configure the behavior of anynode 21-24 by generating a script image 52, which can include functioncalls for any of the core functions 51 or for any function defined by ascript image 52 uploaded to a node.

In addition, as will be described in more detail hereafter, it ispossible for any node 21-24 to use a remote procedure call to invoke afunction stored on any of the other nodes of the network 20. As usedherein a “remote” procedure call refers to any procedure call that iscommunicated from one node to another such that the procedure call isexecuted on a node that is remote from the one that originallytransmitted the procedure call.

To better illustrate the foregoing, assume that the node 24 is coupledto a sensor 125 and that the node 22 is coupled to an apparatus 126, asshown by FIG. 3. For illustrative purposes, assume that the sensor 125is a switch that is activated when toggled by a user and that theapparatus 126 is a light source that is to emit light when the sensor125 is activated. Further assume that the script image 52 stored at thenode 24 includes a function, called “Check_Switch,” that is configuredto monitor the sensor 125 and determine when it is activated. Furtherassume that one of the core functions 51 of the node 24 named “RPC” isconfigured to transmit a remote procedure call message through thenetwork 20. Also assume that a script image 52 at the node 22 includes afunction called “Light_On” that, when executed, transitions theapparatus 126 into a state such that it emits light.

While running on the virtual machine 53 of node 24, assume that theCheck_Switch function detects activation of the sensor 125. In response,the Check_Switch function is configured to call the RPC function 51 and,in the function call, to pass the name of the function to be called(i.e., “Light_On” in the instant example) and the address of the node22. Thus, the RPC function is called by the virtual machine 53 of thenode 24, and the RPC function causes an RPC message including thefunction name “Light_On” to be transmitted as a unicast message to thenode 22.

Upon reception of the RPC message, the virtual machine 53 of the node 22invokes the Light_On function based on the function name in the remoteprocedure call. In this regard, the RPC includes as payload data thefunction name “Light_On” and overhead information that identifies themessage as an RPC. Thus, when executing the function call, the virtualmachine 53 of node 22 searches the function catalog 61 for the name“Light_On” indicated by the payload data. Upon locating such name, thevirtual machine 53 uses the associated pointer in the function catalog61 to locate and then execute the Light_On function. When executed, theLight_On function changes the state of the apparatus 126 such that itbegins emitting light. In a similar manner, a function at any node ofthe network 20 can be written to call a function stored at any othernode. In other examples, other types of functionality could be enabledby the network 20.

As described above, the I/O interface 78 (FIG. 2) of any of the nodes21-24 may be coupled to any external device. In one exemplaryembodiment, at least one node 21-24 is coupled to a host that is used toupload at least one script image 52. For example, FIG. 3 depicts anexemplary embodiment in which the I/O interface 78 of the node 21 iscoupled to a host 110. In one exemplary embodiment, the host 110 is acomputer, such as a desk-top, lap-top, or hand-held computer, but othertypes of devices may be used to implement the host 110 in otherembodiments. Further, the host 110 may be coupled to the node 21 via aconductive medium to allow data to be exchanged between the host 110 andthe node 21. For example, the host 110 and node 21 could communicateover a communication connection via RS-232 protocols or other types ofprotocols. Alternatively, the host 110 may be configured to communicatewith the node 21 via wireless signals.

FIG. 4 depicts an exemplary embodiment of the host 110. As shown by FIG.4, the host 110 comprises host core logic 152 for generally controllingthe operation of the host 110, as will be described in more detailbelow. It should be noted that the core logic 152 can be implemented insoftware, firmware, hardware, or any combination thereof. In theexemplary embodiment illustrated in FIG. 4, the core logic 152 isimplemented in software and stored in memory 155 of host 110.

Various code, such as script source 161, bytecode 162, script image 52,a source parser 164, a code translator 165, and GUI logic 166 are alsostored in memory. Note that, in other embodiments, at least portions ofthe source parser 164, code translator 165, and the GUI logic 166 can beimplemented in hardware, firmware, or any combination of hardware,software, and firmware. When implemented in software, the core logic152, the source parser 164, code translator 165, and the GUI logic 166can be stored and transported on any computer-readable medium for use byor in connection with an instruction execution apparatus that can fetchand execute instructions.

The exemplary embodiment of the host 110 depicted by FIG. 4 comprises aprocessing element 172, which comprises processing hardware forexecuting instructions stored in memory 155. The processing element 172communicates to and drives the other elements within the host 110 via alocal interface 175, which can include at least one bus. Furthermore, auser input interface 176, for example, a keyboard or a mouse, can beused to input data from a user of the host 110, and a user outputinterface 177, for example, a display device (such as a liquid crystaldisplay) or printer, can be used to output data to the user.Furthermore, an input/output (I/O) interface 178 enables the host 110 tocommunicate with external devices, such as node 21. For example, the I/Ointerface 178 may be conductively or otherwise communicatively coupledto the I/O interface 78 of node 21 or other device.

The host 110 also has a network interface 179 for enabling it toexchange data with a network 181, such as a wide area network (WAN) orlocal area network (LAN). As an example, the network interface 179 maybe configured to communicate with the Internet via transmission controlprotocol/Internet protocol (TCP/IP).

When a user wishes to program a node of the network 20 to perform adesired function, the user writes script source 161 defining a scriptfor execution by the node. In one exemplary embodiment, the scriptsource 161 is source code that is written in Python, but the scriptsource 161 may be written in other languages, if desired. A conventionalsource parser 164 parses, compiles, and tokenizes the script source 161to provide bytecode 162 capable of being executed. A code translator 165translates the bytecode 162 into a script image 52 that can betransmitted to and run on the virtual machine 53 (FIG. 2) of any node ofthe network 20. In particular, the code translator 165 analyzes thebytecode 162 and performs various optimizations that make running of thescript image 52 on an embedded virtual machine 53 more efficient.

As an example, the code translator 165 analyzes the bytecode 162 forglobal variables, which typically are stored in random access memory(RAM). The code translator 165 attempts to identify any variables in thebytecode 162 that are not changed at run time. For example, assume thatthe bytecode 162 has an instruction that initializes a value of thevariable, but the bytecode 162 does not have an instruction forassigning a new value to the variable. In such a case, the value of thevariable is not changed by the bytecode 162 after initialization. If thecode translator 165 identifies such a variable, the translator 165changes the data type from variable to constant in the script image 52.Further, the virtual machine 53 of each node is configured to storeconstants in a memory other than RAM, such as flash memory. Thus,variables that are re-classified as constants do not consume RAM,thereby helping to reduce the RAM size requirements. Other types ofoptimizations could be performed by the code translator 165.

The script image 52 provided by the code translator 165 is capable ofrunning on the virtual machines 53, which are Python bytecodeinterpreters in one exemplary embodiment. The host core logic 152 isconfigured to transmit the script image 52 to the node 21 along with thenode address or addresses of the network node or nodes on which thescript image 52 is to be stored and executed. If the node 21 isidentified, the script image 52 is stored in memory 55 of the node 21.For example, one of the core functions 51 may be a process for storing ascript image 52 in memory 55. As part of this process, the core function51 updates the function catalog 61 to include an entry for functionnames of the functions in the script image 52. Thus, any of the scriptfunctions can be later invoked via execution of a function callidentifying the name of the function. In this regard, when the virtualmachine 53 executes a function call having the name of a function withinthe script image 52, the virtual machine 53 consults the functioncatalog 61 to locate the script's name within the catalog 61 and theassociated pointer. The virtual machine 53 may then use the pointer toinvoke the function being called.

If the destination address received along with the script image 52 fromthe host 110 identifies a node other than the node 21 coupled to thehost 110, then the node 21 transmits the script image 52 to theidentified node. In this regard, the stack 54 packetizes the scriptimage 52 into at least one data packet, which has a header identifyingthe destination. For example, if the script image 52 is to be uploadedto node 23, then the destination address of the packet identifies thenode 23. In such case, the packet is wirelessly transmitted by thecommunication device 77 of the node 21 to the node 23, which receivesthe packet and stores the packet in the packet buffer 65. The stack 54depacketizes the packet and provides the payload data of the packet,which is at least a portion of the script image 52, to the virtualmachine 53 of node 23. The virtual machine 53 of the node 23 stores thescript image 52 in memory 55 and updates the function catalog 61 similarto the techniques described above for storing the script image 52 in thenode 21. Thus, any function of the script image 52 can be invoked andexecuted by the virtual machine 53 of the node 23 in response toexecution of a function call that includes the function's name.

In one exemplary embodiment, the function catalog 61 is updated based ona list of functions received from the host 110 that generated the scriptimage 52. In this regard, the code translator 165 generates a list offunctions that are in the script image 52 and pre-sorts the list inalphabetical order or some other logical order. In addition totransmitting the script image 52 to the node 23 that is to run thescript image 52, the host core logic 152 also transmits the list ofpre-sorted function names to such node 23. The node then replaces thefunction names currently in its function catalog 61 with the newlyreceived list from host 110. The node also defines the pointers for thefunctional catalog 61 based on where each respective function is storedin the node's memory 55.

Note that the core function 51 for storing the script image 52 in memory55 and updating the function catalog 61, as described above, stores thescript image 52 in the language native to the virtual machine 53. Thus,no translation of the script image 52 is performed by the operationsthat write and read the script image 52 to and from memory 55. Forexample, when the virtual machine 53 is implemented as a Python bytecodeinterpreter, as described above, the code defining the script image 52is stored in memory 55 as a Python data type. Thus, when the scriptimage 52 is stored in memory 55, it can be executed by the virtualmachine 53 without any further translation.

In one exemplary embodiment, the host 110 has an address within thenetwork 20 such that the host 110 is essentially another node of thenetwork 20. Indeed, as shown by FIG. 4, the host has a virtual machine53 and core functions 51, like the other nodes 21-24 of the network 20.Thus, any node 21-24 of the network 20 can transmit a script image 52 tothe host 110, which executes the script image 52 via its virtual machine53. Accordingly, the resources of the host 110, such as the networkinterface 179, are available to the other nodes 21-24 of the network 24.In addition, although not shown in FIG. 4 for simplicity ofillustration, the host 110, like any of the other nodes of the network20, may comprise a function catalog 61, configuration parameters 63, anda packet buffer 65.

For example, FIG. 5 depicts an embodiment in which a node 226 of thenetwork 20 is located remotely from the other nodes 21-24 and host 110.As shown by FIG. 5, each node 21-24 and host 110 have routing tables231-235, respectively. The routing tables 231-235 include informationindicative of the routes that messages are to take in the network 20.Each node 21-24, including host 110, uses its respective routing tableto determine how to define the header information of a packet dependingon the packet's destination. The use of routing tables is generallywell-known in network communications.

The node 226 is communicatively coupled to the host 110 via a network181, such as the Internet. As described above, the host core logic 152may communicate with the network 181 via the network interface 179 (FIG.4). In one exemplary embodiment, the node 226 transmits messages toother nodes 21-24 through the network 181 and the host 110, and any ofthe nodes 21-24 may transmit messages to the node 226 through the host110 (which as indicated above is one of the nodes of the network 20) andthe network 181. Exemplary techniques for achieving such communicationwill be described in more detail below.

In this regard, to join the network 20, the node 226 is aware of theaddress of the host 110 for the network 181 (e.g., entered or selectedby a user of the node 226). For example, if the network 181 is anInternet Protocol (IP) network, then the node 226 is aware of the IPaddress of the host 110. Note that the host's IP address is differentthan the host's address for the network 20. In this regard, to route amessage to the host 110, the other nodes 21-24 use the host's addressfor the network 20. As described in more detail herein, in one exemplaryembodiment, the address of a node of the network 20 is a portion of thenode's media access control (MAC) address. Thus, the host 110 has anaddress for network 20 that is a portion of the host's MAC address, andthe host 110 has an entirely different IP address used by the network181 to route messages to the host 110. In other embodiments, other typesof addresses may be used.

Using the IP address of host 110, the node 226 transmits a messagethrough the network 181 for informing the host 110 of the node'spresence. The message includes the address of the node 226 for thenetwork 20 and the address of the node 226 for the network 181. Asdescribed above, in one embodiment, the address of the node 226 for thenetwork 20 is a portion of the MAC address for the node 226.

Upon receiving the message 110, the host core logic 152 is configured toupdate the routing table 235 of the host 110 to include the address ofthe node 226 for the network 20. The other nodes 21-24 of the network 20may discover the node 226 by broadcasting a route discovery message, aswill be described in more detail hereafter. Other techniques fordiscovering nodes and updating routing tables are possible in otherembodiments.

If any node 21-24 is to transmit a message to the node 226, such node21-24 transmits a message that is routed to the host 110. The host corelogic 152 is configured to encapsulate the message in one or morepackets compatible with the network 181. For example, if the network 181is the Internet as described above, then the core logic 152 isconfigured to encapsulate the message in one or more Transmit ControlProtocol/Internet Protocol (TCP/IP) packets and to include the addressof the node 226 for the network 181 in such packets. Note that the corelogic 152 may encapsulate just the payload data of the packets of thenetwork 20 defining the message, or the core logic 152 may encapsulateportions of the header information as well, if desired. The host controllogic 110 then transmits the TCP/IP packet to the network 181, whichroutes this packet to the node 226. The node 226 depacketizes the TCP/IPpacket to recover the original message.

Accordingly, packets can be transmitted by any of the nodes 21-24, 110and host 110 to the node 226 utilizing the network 181 and resources ofthe host 110. Note that the use of the network 181 is transparent to thenodes 21-24. In this regard, when a node 21-24 desires to transmit amessage to the remote node 226, the node 21-24 uses the address of thenode 226 for the network 20. Thus, the transmitting node 21-24 transmitsthe message as if the node 226 is coupled directly to the host 110without an intervening network 181. Further, it is unnecessary for thetransmitting node 21-24 to be aware of the address of the node 226 forthe network 181 or even to be aware of the presence of the network 181.Moreover, the host 110 handles the interfacing of the message with thenetwork 181.

Note that the node 226 can transmit a message to any of the nodes 21-24,110 in the reverse direction. In this regard, the node 226 defines amessage to be transmitted and packetizes the message using a protocolcompatible with the network 181. Further, the node 226 includes theaddress of the destination node. The node 226 transmits the data packetor packets through the network 181 to the host 110, and the host corelogic 152 depacketizes such data packets to recover the message to betransmitted to the destination node 21-24. The host 110 then packetizessuch message using a protocol compatible with the network 20 andtransmits the data packet or packets formed by the host 110 to the node21, which routes the message through the network 20 as appropriate.Thus, any of the nodes 21-24 can communicate in either direction withthe remote node 226 using the host 110 and network 181 even though thepresence of the network 181 is transparent to such nodes 21-24.

In addition to enabling extension of the network 20 across anothernetwork 181, the host 110 can be used to monitor the network 20 and/orchange the configuration and behavior of the network 20, as will befurther described hereafter. As shown by FIG. 4, the host 110 comprisesGUI logic 166 that is configured to display a GUI to a user. FIG. 6depicts an exemplary GUI 305 displayed by the GUI logic 166. Theexemplary GUI 305 of FIG. 6 has at least three windows 307-309. Othernumbers of windows are possible in other examples.

Window 307 lists the nodes of the network 20. In this regard, for eachnode, the window 307 includes various information, such as the node'sname, the node's address within network 20, the name of the script image52, if any, stored at the node, the quality of the network communicationlink recently used by the node, and the device type of the node. Othertypes of information can be indicated in other examples.

Note that the node name can be defined by the user of the host 110 orotherwise. In one exemplary embodiment, a default name is randomlyassigned to each node such that each node is assigned a unique name. Ifthe user of the host 110 desires to change any of the default names, theuser provides inputs, via the user input interface 176, for changing thedefault names. In response, the core logic 152 updates the node name asspecified by the user. In one exemplary embodiment, the name of a givennode is stored in the node. In such an embodiment, when the user changesa node name, the host core logic 152 transmits, to the node identifiedby the updated name, a remote procedure call for updating the node'sname. Thus, the node name stored at the node is updated.

The device types can be defined and categorized in any useful manner. Inone exemplary embodiment, a device type of “Portal” refers to a node,such as host 110, that can interface with a user in order to monitor andchange the configuration and behavior of the network 20. A device typeof “bridge” refers to a node, such as node 21, that has a direct link toa Portal node. A bridge node can be used by a Portal node to communicatewith other nodes of the network 20. In one exemplary embodiment, eachPortal node is coupled to a bridge node via a physical medium, such as aRS-232 connection. As an example, a Portal node may be implemented as apersonal computer that is coupled to a bridge node in order to enablecommunication with other nodes of the network 20. In such an example,the personal computer has an address for the network 20 that can be usedby the other nodes of the network 20 to communicate with the personalcomputer via the network 20. Other types of devices may be used toimplement a Portal node in other embodiments.

In one exemplary embodiment, the host 110 receives the informationdisplayed in the window 307 from the nodes of the network 20. In thisregard, in order to discover the topology of the network, the hostcontrol logic 110 transmits a multicast message instructing each node21-24 receiving the message to reply with information, referred to as“node status information,” which includes at least the informationdisplayed in window 307. This multicast message is received by the node21, which then broadcasts the message to the other nodes 22-24 of thenetwork 20. Upon receiving the message, each node 21-24 rebroadcasts themessage, since it is a multicast message, and also replies with aunicast message for the host 110. In this regard, the node uses thesource address (which identifies the host 110 in this example) from themulticast message for addressing the unicast message for the host 110.The unicast message includes, as payload data, the node statusinformation requested by the multicast message, such as the name of thenode, the address of the node, the name of the script image 52, if any,at the node, the most recent network link quality for the node, and thenode's device type.

Using the user input interface 177 (e.g., a mouse), the user can selectany of the nodes listed in the window 307, and the selected node ishighlighted. For example, in FIG. 6, a node named “McastCounter” isselected by a user and, therefore, appears highlighted in the window307. Information about the selected node is also displayed in the window308. In the exemplary embodiment depicted by FIG. 6, the informationdisplayed for the selected node includes the node name, the version offirmware running on the node, the node's address for network 20, thenode's media access control (MAC) address, the node's device type, thename of the node's script image 52 (referred to as “device image” in theGUI 305), if any, a cyclical redundancy check (CRC) value for the scriptimage 52, if any, the byte size of the script image 52, if any, thechannel identifier for the channel on which the node is currentlycommunicating, and the node's address within the network 20. Suchdisplayed information within window 308 may be part of the node statusinformation returned to the host 110 during network discovery. Note thata network discovery can be initiated at anytime by the user of the host110 or otherwise (e.g., automatically) in order for the host 110 torefresh its network topology to account for nodes that may join or leavethe network 20 from time-to-time. In other embodiments, other types ofinformation may be displayed by window 308.

The CRC value within the node status information transmitted to the host119 is the result of a calculation performed on the bytecode scriptimage 52 at the node in which the script image 52 is stored. Thus, aswill be described in more detail hereafter, by performing the samecalculation on a version of the script image 52 and comparing the resultof this calculation to the CRC value stored at the node, it is possibleto determine whether the foregoing version matches the script image 52stored at the node.

Also shown in window 308 for the selected node, “McastCounter,” is alist 312 of function names for the core functions 51 as well as thefunctions defined by the script image 52 stored at the node. Similar tothe other information displayed by window 308, the list 312 may be partof the node status information returned to the host 110 during networkdiscovery. In one exemplary embodiment, the list 312 is based on thefunction catalog 61 stored at the selected node. In this regard, themulticast message transmitted by the host 110 during network discoverydefines a remote procedure call that invokes at least one of the corefunctions 51. This core function 51 retrieves the node statusinformation, including the function names stored in the function catalog61, and transmits such retrieved information to the host 110. The nodestatus information retrieved and transmitted by the core function 51 isthen displayed in the window 308 of GUI 305 when the user selects thename of the node in the window 307.

Alternatively, the function catalog 61 may be stored at the host 110such that retrieval of the function catalog 61 from the selected node isunnecessary. As described above, the function catalog 61 can be createdby the host 110 when generating the bytecode script image 52 from ascript source 161. The host core logic 152 may be configured to archiveeach function catalog 61 for the various nodes configured by the host110. In such case, the function names displayed in window 308 can beretrieved from the host's memory 155 without being retrieved from theselected node. Other types of node status information may be similarlyarchived by the host 110 such that retrieval of such information fromthe nodes is unnecessary.

The window 309 displays information about various events that haveoccurred at the node selected in window 307. Each event is time stamped.The displayed events could include messages received from other networknodes and/or events detected by the script image 52 running at theselected node. Such events are logged at the selected node andtransmitted to the host 110.

Note that the GUI 305 may be displayed in various formats. For example,FIG. 7 shows an exemplary iconic GUI 305 in which the network nodes arerepresented by icons in window 307. Various other formats are possiblein other examples.

In one exemplary embodiment, the function names in the window 312 areselectable hyperlinks. When the user selects the hyperlink for one ofthe function names via the user input interface 177, the host core logic152 transmits a unicast message to the node identified by theinformation being displayed in the window 308. The unicast messagecomprises a remote procedure call for the selected function. Uponreceiving the message, the function identified by the remote procedurecall is invoked and executed. Thus, selecting the function namedisplayed by the host 110 results in execution, at the remote node(i.e., the node selected in window 307), of the selected function.

In addition, the script name displayed within window 308 also appears asa selectable hyperlink 361. When the hyperlink 361 is selected, the hostcore logic 152 displays the script source 161 of the identified scriptto the user, if such script source 161 is available to the host 110. Inone exemplary embodiment, the script source 161 is displayed in a newwindow 308, as shown by FIG. 8. Note that there are a variety oftechniques that may be used by the host core logic 152 to locate anddisplay the script source 161 requested by the user via selection of thescript name in the window 308 or otherwise.

In one exemplary embodiment, the script source 161 for each script image52 generated by the host 110, as well as the generated script image 52,are retained in memory 155 and correlated with an address of the node towhich the script image 52 is pushed by the host 110. Note that thememory 155 may include disks that can be transmitted from one computersystem to another. The script source 161 is accessible to the host corelogic 152 so that the script source 161 can be retrieved if it is laterrequested by a user of the host 110. However, before displaying thescript source 161 in response to the request, the host core logic 152firsts performs at least one test to determine whether the version ofthe script source 161 stored at the host 110 is obsolete. If so, thehost core logic 152 warns the user.

For example, assume that the user requests the script image 52 stored atthe node 23. As described above, the host 110 for each node retains thenode's script image 52 generated at the host 110. In one exemplaryembodiment, when the user requests the script image 52 stored at thenode 23, the host core logic 152 is configured to retrieve the scriptimage 52 for the node 23 stored at the host 110. The logic 152 isfurther configured to calculate a CRC value based on the retrievedscript image 52 and to compare this calculated CRC value to the CRCvalue provided by the node 23 during network discovery or otherwise.Note that all nodes of the network 20 are configured to calculate CRCvalues according to the same algorithm. Thus, if the CRC valuecalculated by the host core logic 152 matches the CRC value from thenode 23, then the core logic 152 determines that the script image 52stored at the host 110 for the node 23 matches the script image 52stored at the node 23. Thus, the logic 152 assumes that thecorresponding script source 161 for the node 23 (i.e., the script source161 from which the script image 52 at node 23 was originally generated)stored at the host 110 is not obsolete. However, if the two CRC valuesdo not match, then the logic 152 assumes that the script image 52 storedat the host 110 for the node 23 does not match the script image 52stored at the node 23. In such case, the core logic 152 determines thatthe corresponding script source 161 for the script image 52 stored atthe host 110 is obsolete and warns the user.

In another embodiment, each time a script image 52 is pushed to anetwork node, the script source 161 from which the script image 52 wasgenerated is also pushed to and stored at the node. Thus, the host 110can request retrieval of a node's script source 161 directly from thenode. Further, each time the node's script is updated, the source codeis updated (e.g., replaced with the source code from which the uploadedscript was generated). Thus, in such an embodiment, the script source161 stored at the node should never be obsolete.

In any event, when a user requests a node's script source 161, the hostcore logic 152 is configured to locate and display the requested scriptsource 161. The user may change the script source 161 in any desiredmanner. Once the script source 161 changes are complete, the usersubmits a request for the script source 161, as changed by the user, tobe uploaded to a node. The user may specify that the modified scriptsource 161 is to be uploaded to the same node identified within thewindow 308, or the user may specify that the modified script source 161is to be uploaded to other nodes or a group of nodes. In response to theuser's request, the core logic 152 invokes the source parser 164 andcode translator 165 to convert the modified script source 161 into atokenized script image 52 that can be executed by the nodes. The logic162 then uploads the script image 52 to the identified node, and thisnode replaces its current script image 52 with the new script receivedfrom the host 110.

As a mere example, assume that the script source 161 for the scriptimage 52 running on the node 23 is displayed to the user and that theuser has modified this source code 161. Further assume that a scriptimage 52 generated from the modified script source 161 is to replace thescript image 52 currently running on the node 23. In one exemplaryembodiment, the core logic 152 transmits, to the node 23, a unicastmessage defining a remote procedure call for one of the core functions51 that causes the node to stop executing its script image 52. The corelogic 152 then transmits, to the node 23, another unicast messagedefining a remote procedure call for one of the core functions 51 thaterases the script image 52 currently stored at the node 23. The corelogic 152 then transmits another unicast message to the node 23 defininga remote procedure call for one of the core functions 51 that writesdata to the node's memory 55. The core logic 152 also transmits the newscript image 52 to the node 23 via at least one unicast message suchthat the function 51 invoked by the foregoing remote procedure callwrites the new script image 52 to the memory 55. The core logic 152 alsotransmits a unicast message to the node 23 defining a remote procedurecall for one of the core functions 51 that causes the node 23 to reboot.

Thus, via execution of the core functions 51 called by the foregoingremote procedure calls, execution of the current script image 52 isstopped, the current script image 52 is erased from memory 55, the newscript image 52 is written to memory 55, and the node 23 is rebooted.After the reboot, the new script image 52 runs such that thefunctionality of the node 23 is controlled by the new script image 52.In a similar manner, the script image 52 stored at any node of thenetwork 20 can be updated as may be desired in order change the behaviorof such node.

To illustrate the ease at which the behavior of the network 20 can bedefined and modified, assume that a user wishes to monitor the sensor125 (FIG. 3) in one part of a manufacturing facility and to turn on alight in another part of the facility based on the sensor 125. Assumethat the user has a personal computer that he intends to use as the host110. The user purchases the nodes 21-24 and sets them up in his facilityas may be desired. For example, assume that the user couples node 21 tothe host 110, and he couples node 24 to the sensor 125 and node 22 tothe apparatus 126, as shown by FIG. 3. The user also downloads a suiteof software including the core functions 51, virtual machine 53, stack54, source parser 164, code translator 165, and core logic 152 to thehost 110. Once the nodes 21-24, 110 are powered up, they are able tocommunicate as a mesh network 20. In this regard, the nodes 21-24, 110automatically communicate with one another to learn of each other'spresence on the network 20 and to define routing tables for routingunicast messages through the network 20.

In addition, the core logic 152 of the host 110 discovers the topologyof the network 20 by broadcasting a multicast message that isrebroadcast by the nodes 21-24. Each node 21-24 replies with a unicastmessage including various node status information, as described above.Thus, the core logic 152 learns the topology of the network 20 anddisplays a list of the nodes 21-24 in a GUI 305.

Within the window 307, the user selects the name of the node 24 that iscoupled to the sensor 125. In response to such selection, the nodestatus information for this node 24 is displayed in window 308. Since ascript image 52 has yet to be defined for this node 24, only the namesof the core functions 51 are displayed. The user then provides an inputindicating that he would like to define a new script. In response, awindow is created in which the user can write script source 161 todefine the new script. Upon completion, the source parser 164 and codetranslator 165 convert the script source 161 to a tokenized script image52, which can be executed on the node 24. The script image 52 isassigned the same name as the script source 161 and is transmittedthrough the network 20 to the node 24. In addition, the code translator165 generates a list of function names that are within the script image52 and pre-sorts the function names in alphabetical order or some othertype of order. This list of function names is also transmitted to thenode 24.

The node 24 stores the script image 52 in memory 55, and the functioncatalog 61 of the node 24 is updated to include the list of functionnames received from the host 110 and the associated pointers. The node24 is then rebooted. Upon reboot, the script image 52 begins runningand, therefore, in the instant example begins monitoring the sensor 125.Note that the communication of the script image 52 through the network20 is transparent to the user. In this regard, the user simplyidentifies which node 24 is to receive the script image 52, and thescript image 52 is automatically transmitted as requested.

Similarly, the user may define and push, to the node 126, a script image52 for controlling the apparatus 126. For example, the script image 52may define a function, called “Light_On,” that is called by the scriptimage 52 of the node 24 when such script image 52 senses activation ofthe switch 125. In the instant example, the called function activatesthe apparatus 126 such that it begins emitting light. Thus, when thescript image 52 of the node 24 detects activation of the sensor 125, thescript image 52 transmits to node 22 a remote procedure call that callsthe function “Light_On.” Upon execution of the remote procedure call,the virtual machine 53 of the node 22 checks the function catalog 61 ofsuch node 22 for the function name “Light_On.” Upon locating such name,the virtual machine 53 invokes the named function, which causes theapparatus 126 to emit light. At any time, the scripts 52 at either ofthe nodes 22 and 24 may be updated to implement new functionalityaccording to techniques described above.

Note that the use of remote procedure calls to invoke new functionsfacilitates the dynamic configurability of the network 20. In thisregard, the format for a remote procedure call includes as payload datathe name of a procedure to be called. The remote procedure call alsoincludes overhead information that identifies the message as being aremote procedure call. Thus, each remote procedure call is of the samemessage type in which the data carried by the message can be controlledin order to reference a particular function or script. Therefore, when anew function is defined, it is unnecessary to create a new message typein order to invoke the function. In this regard, to invoke the function,a remote procedure call, which is of a message type known by all of thenetwork nodes, can be generated, and the name of the new function can beinserted into the data portion of the message. Each node, uponidentifying the message as a remote procedure call based on themessage's overhead, is configured to read this data portion and thencompare the read data to the function list defined by the functioncatalog 61 in an effort to locate the address of the function to beexecuted in response to the remote procedure call. Accordingly, a remoteprocedure call can be used to invoke a newly defined function, and it isunnecessary for the user who writes a new function to define a newmessage type or even be aware of the communication protocols used by thenetwork 20.

It should be noted that there are various techniques that may beemployed to enable the network 20 to operate more efficiently andotherwise better. For example, in one exemplary embodiment, the networkaddresses are predefined such that each node has a network address uponjoining the network 20. In this regard, in a conventional network, anode is often assigned a network address by a coordinator node. In thisregard, a node that is attempting to join a network transmits a messageindicating the node's desire to join the network. A coordinator thenreplies with a network address that is unique within the network. Thisnetwork address is thereafter used to identify the node within thenetwork 20.

In the network 20, each node defines its network address to be at leasta portion of its MAC address. For example, in one embodiment, each nodeuses as its network address the least significant three bytes of its MACaddress. In other examples, other portions of the MAC address or othertypes of predefined addresses may be used. Thus, each node is aware ofits network address without having to first contact a coordinator to beassigned such an address. Therefore, the node is able to join thenetwork 20 and begin communicating through the network 20 quicker thanwould otherwise be possible if the node had to wait on a coordinator toassign it an address within the network 20.

In one exemplary embodiment, the communication device 77 (FIG. 2) ofeach node 21-24 is configured to provide a signal, referred to hereafteras “energy level signal,” indicative of the amount of energy detectedfor the channel being used by the node for network communication. Beforewirelessly transmitting a message via the same channel, the node's stack54 analyzes the energy level signal. If the energy level signal is abovea predefined threshold, the stack 54 determines that there is trafficbeing communicated through the network 20 via the channel. Thus, thestack 54 waits before sending the message in an effort to avoid a datacollision with the traffic. In this regard, the stack 54 waits apredefined time interval and then again checks the energy level signal.If it is still above the threshold, the stack 54 continues waiting. Thestack 54 continues waiting in such manner until the stack 54 determinesthat the energy level signal is below the threshold. When this occurs,the stack 54 proceeds with transmitting the message by sending themessage to the communication device 77 for wireless transmission.Accordingly, data collisions within the network 20 are reduced.

In one exemplary embodiment, the energy level signal is checked by thestack 54 immediately after transmission of a message by thecommunication device 77. If the energy level is above a predefinedthreshold, then the stack 54 assumes that the message collided withother traffic or noise on the channel at the time of transmission. Thus,it is unlikely that the message was successfully received by anothernode of the network 20. In such a situation, the stack 54 retransmitsthe message via the communication device 77.

If, however, the energy level signal is below the predefined thresholdimmediately after transmission of a message through the channel by thecommunication device 77, then the stack 54 assumes that no collisionoccurred with other traffic or noise. Thus, the stack 54 does notattempt to retransmit the message unless it receives another indicationthat the message was not successfully received (e.g., if the stack 54fails to receive an acknowledgement for the message after a predefinedtime period from transmission).

As indicated above, multicast messages are rebroadcast by nodes of thenetwork 20 in an attempt to inform other nodes of the multicast message.However, in one exemplary embodiment, a node determines whether torebroadcast a multicast message based on the energy level signalprovided by the communication device 77. In this regard, the stack 54buffers values of the energy level signal so that the stack 54 cananalyze the buffered values to determine the recent state of the energylevel signal. When a multicast message is received by the communicationdevice 77, the stack 54 analyzes the buffered energy level signal valuesto determine a value of the energy level signal when the multicastmessage was being received by the communication device 77. Such valueindicates the strength of the multicast message at the time ofreception. In this regard, a higher energy level signal value indicatesa higher strength or power level for the message.

Moreover, a high power level for the message suggests that the nodetransmitting the message is close to the receiving node. For purposes ofillustration, assume that the node 21 is the transmitting node, andassume that the node 22 is the receiving node. If a message transmittedfrom the node 21 to the node 22 is associated with a high energy levelsignal value (i.e., the energy level signal provided by thecommunication device 77 of node 22 is high at the time of reception bynode 22), it is likely that any node that is within the transmissionrange of node 22 is also within the transmission range of node 21,assuming that the transmit power of node 21 is similar to that of node22. Thus, the benefit of having the node 22 rebroadcast the multicastmessage in such a case is relatively low.

In one exemplary embodiment, the stack 54 of the receiving node isconfigured to compare a predefined threshold to the energy level valueassociated with a received multicast message (e.g., a value of theenergy level signal while the multicast message is being received by thecommunication device 77). If the energy level value is below thethreshold, then the stack 54 is configured to rebroadcast the multicastmessage. However, if the energy level value is above the threshold, thenthe stack 54 refrains from rebroadcasting the message. Accordingly, thetotal number of times that the nodes of the network 20 rebroadcast amulticast message can be reduced without significantly limiting therange of the multicast message.

Various other techniques for improving communication within the networkare possible.

Note that sleeping nodes can cause problems and/or inefficiencies innetwork communications. For example, as described herein, many messageshop through a network from node-to-node until arriving at theirrespective destinations. Moreover, the routing tables 231-235 in thenetwork nodes indicate data paths over which messages may travel.However, sleeping nodes may disrupt such data paths. As a mere example,consider a situation in which a message from node 21 is to hop throughnode 23 in order to arrive at node 24. If node 23 transitions to a sleepstate, then the message from node 21 cannot reach node 24 via theaforementioned data path while the node 23 is sleeping.

In such a situation, the node 21 may attempt to send the message unawarethat the node 23 is in a sleep state. Since the node 23 is sleeping, itdoes not receive the message nor send an acknowledgement. Accordingly,the node 21 may attempt several retransmissions. After several attemptedretransmissions, the node 21 may stop its efforts to communicate throughnode 23. In such a situation, the node 21 may try to discover anotherroute to reach the node 24 by broadcasting a message to other nodes thatmay be able to communicate with the node 24 via a different route. Ifanother route can be located, then the node 21 may attempt to transmitthe message to the node via the other route. However, the time requiredto find the other route and the time utilized to attempt communicationwith the node 23 before realizing that this node 23 is not presentlyavailable for routing increase the delay in communicating the message tothe node 24. In addition, the unsuccessful attempts to transmit to thenode 23 and the messages related to the discovery of the new routeincrease the traffic on the network 20 and possibly increase datacollisions thereby decreasing the overall efficiency of the network 20.

Due to the problems and inefficiencies caused by sleeping nodes innetwork communications, many conventional networks, particularly meshnetworks in which each node controls the transmission times of its ownoutgoing messages, are configured such that nodes are not allowed totransition to sleep states. Thus, the network is generally kept up andrunning so that any node at any time can successfully transmit messagesthrough the network. However, preventing nodes from transitioning tosleep states undesirably increases the power requirements of the nodes.

In one exemplary embodiment, at least some of the nodes 21-24, 110 ofthe network 20 are allowed to transition to sleep states such that thesleeping nodes are unable to communicate with other nodes while in thesleep state. For example, a node 21-24 may power down its communicationdevice 77 and/or other components that enable network communicationwhile in a sleep state thereby conserving electrical power. U.S. patentapplication Ser. No. 12/253,086, entitled “Systems and Methods forReducing Power Consumption in Communication Networks,” and filed on Oct.16, 2008, which is incorporated herein by reference, describes exemplarytechniques for controlling sleep states of network nodes. In oneexemplary embodiment, the data paths for the network 20 are based on thesleeping characteristics of the nodes 21-24, 110 in an effort to reduceinefficiencies and problems caused by sleeping nodes in the network 20.

In this regard, as described above and shown by FIG. 5, the nodes 21-24have routing tables 231-235 that indicate data paths for messages to becommunicated through the network 20. To better illustrate aspects ofpacket routing, exemplary techniques for defining the routing tables231-235 will be described in more detail below. However, it should beemphasized that various other techniques may be used to define therouting tables 231-235.

Referring to FIG. 5, assume that the node 22 has already discovered adata path to node 24. In this regard, assume that the routing table 232indicates that a message destined for the node 24 is to hop through thenode 23. In this regard, there is an entry for each route defined by thetable 232. The entry for the data path to the node 24 includes theaddress of node 24 as the destination and the address of the node 23 asthe next hop in order to reach such destination. Note that there is noneed for the table 232 to include the addresses of other hops, if any,along an indicated data path.

If the node 22 is to transmit a message to the node 24, the node 22transmits a message via at least one data packet. The data packet has aheader, which includes a destination address that identifies node 24 anda hop address that identifies node 23. In addition, the routing table233 of node 23 indicates that a message destined for the node 24 may becommunicated directly to the node 24. Thus, when the node 23 receivesthe foregoing data packet destined for the node 24, the node 23 forwardsthe packet to the node 24 by changing the hop address to identify node24 and then retransmitting the packet. In such an example, the node 22is the source node, the node 24 is the destination node, and the node 23is a routing node, since a packet from the source to the destination isrouted through the node 23. Note that in other examples, there may bemore than one routing node.

Now assume that the node 21 has yet to discover a route to the node 24but desires to communicate with this node 24. Also assume that the node21 is not within range of the node 24. Therefore, direct communicationbetween nodes 21 and 24 is not possible. To discover a route to the node24, the node 21 broadcasts a message, referred to hereafter as a “routediscovery message.” In one exemplary embodiment, the route discoverymessage is rebroadcast like a multicast message and includes the networkaddress of the node 21 that originally broadcast the message. The routediscovery message also includes the network address of the node 24,referred to as the “destination node,” for which a route is beingsought.

When a node, referred to as the “receiving node,” receives a routediscovery message, the receiving node determines whether it is thedestination node. If it is not the destination node, then the receivingnode rebroadcasts the message. However, unlike many other multicastmessages, the receiving node includes its own identifier in therebroadcast message. Thus, the route discovery message, when it isultimately received at the destination node, will include the networkaddress of the node 21 that originally broadcast the message and theaddresses of all of the hops from such node 21 to the destination node24. Thus, the message indicates a complete route from the node 21 to thedestination node 24. The hop addresses included in the route discoverymessage are used to enable duplicate filtering of the route discoverymessage. In this regard, if any of the hop nodes identified in themessage receives the message from another node of the network 20, thehop node, in response to its own identifier in the message, refrainsfrom rebroadcasting the message. Thus, the destination node 24 isprevented from receiving multiple “pings” of the same route discoverymessage from the same hop node.

The node receiving the route discovery message may be configured toupdate its own routing table based on such message. In this regard, inone exemplary embodiment, if the routing table of the receiving nodedoes not indicate a route for the node 21 that originally transmittedthe route discovery message, then the receiving node updates its routingtable to include an entry for the original transmitting node 21. Thereceiving node also updates such entry to include the address of thenext hop for the route to the original transmitting node 21 based on theaddresses in the route discovery message. In this regard, the address ofthe next hop included in the routing table entry is the address fromwhich the route discovery message was directly received (i.e., theaddress of the last hop for the route discovery message). Thereafter,the entry may be later used to transmit a message to the node 21 thatoriginally transmitted the route discovery message.

If the node receiving the route discovery message determines that it isthe destination node identified in the message, then the node respondsto the route discovery message with a unicast message to the node 21that originally broadcast the route discovery message. In this regard,the unicast message identifies the original transmitting node 21 (i.e.,the source of the route discovery message) and the address of the nexthop, which is the same node from which the route discovery message wasdirectly received by the destination node 24. Therefore, the message isrouted through the path defined by the addresses in the received routediscovery message to the node 21 that originally broadcast the routediscovery message. This node 21 then updates its routing table 231 toappropriately indicate the route to the destination node 24. In thisregard, the node 21 creates an entry in its routing table 231 andincludes the address of the destination node 24. The node 21 alsoincludes the address of the next hop, which is the node from which theunicast message was directly received (i.e., the address of the last hopnode for the unicast message prior to being received by the node 21).Note that each unicast message communicated in the network 20 preferablyincludes the address of the transmitting node (i.e., the node from whichthe message is being transmitted) and, therefore, the address ofmessage's last hop.

In the instant example, assume that the routing table 231 of the node 21indicates that messages destined for the node 24 are to be routedthrough the node 23, which is configured to route such messages directlyto the node 24. Thus, if a message is to be transmitted to the node 24,the node 21, based on the routing table 231, transmits at least onepacket that identifies the node 24 as the destination and the node 23 asthe next hop. Upon receiving the packet, the node 23 forwards the packetto the node 24 based on its routing table 233 by changing the next hopaddress to that of the node 24.

In one exemplary embodiment, the nodes 21-24, 110 are categorized intoat least two categories, routing nodes and routing-disabled nodes. Arouting node is a node that is enabled to function as a hop for unicastmessages transmitted from other source nodes to other destination nodes.A routing-disabled node is a node that is disabled from functioning as ahop for unicast messages transmitted from other source nodes to otherdestination nodes. In other words, a routing-disabled node is preventedfrom routing unicast messages through the network 20. Accordingly, arouting-disabled node can transmit unicast messages that are then routedthrough the network 20 or, in particular, can function as a source forunicast messages. Also, a routing-disabled node can receive unicastmessages that have been routed through the network 20 or, in particular,can function as a destination. However, a routing-disabled node isprevented from forming part of a route for which the routing-disablednode is not the source or the destination in a unicast message.

Therefore, the routing tables 231-235 are defined such that routingnodes may be indicated as next hops for any unicast message. However,the routing tables 231-235 are defined such that routing-disabled nodesare not indicated as the next hop for any unicast message, unless arouting-disabled node is the destination for the unicast message.

In one exemplary embodiment, the nodes 21-24, 110 are categorized asrouting or routing-disabled based on the anticipated sleepingcharacteristics of such nodes 21-24. For example, nodes that are not totransition into sleep states during operation can be categorized asrouting nodes, and nodes that are to transition into sleep states duringoperation can be categorized as routing-disabled nodes. Moreover, sincerouting-disabled nodes are not used for hops of unicast messagesdestined for other nodes, it is less likely that the transition of arouting-disabled node to a sleep state will affect the performance ofthe network 20 for the other nodes. In this regard, while therouting-disabled node is in a sleep state, the other nodes maycommunicate with one another via the network 20 without having todiscover new routes or update their routing tables since the transitionof the routing-disabled node to a sleep state does not affect the dataroutes between such other nodes.

Note that, if desired, some nodes that are to transition to a sleepstate may be categorized as routing nodes. For example, nodes thatrarely (relative to other nodes) transition to a sleep state may becategorized as routing nodes while nodes that more frequently transitionto sleep states may be categorized as routing-disabled. Since nodes thattransition to sleep states more frequently are prevented fromfunctioning as routing nodes, the overall communication efficiency ofthe network 20 may be enhanced. Further, it may be desirable tocategorize a node, referred to as a “sleep-enabled node,” thattransitions to a sleep state as a routing node based on its geographiclocation. For example, depending on the locations of the nodes withrespect to one another, a particular node may be only reachable througha sleep-enabled node. In such a case, it may be desirable to categorizethe sleep-enabled node as a routing node so that communication with theparticular node is enabled at least during the times that thesleep-enabled node is awake. In various other examples, it may bedesirable for routing nodes to be allowed to transition to sleep states.

In addition, routing-disabled nodes are generally allowed to rebroadcastmulticast messages except as may otherwise be described herein. In thisregard, as previously described above, specific data paths are notdefined for multicast messages. Generally, each node that receives amulticast message rebroadcasts the message although, as describedherein, techniques may be employed to ensure that the life of amulticast message is limited. Moreover, since there are not predefinedpaths for multicast messages, the transition of a routing-disabled nodeto a sleep state should not have a significant effect to the overallcommunication efficiency of the network 20 for multicast messages.

Various techniques for preventing routing-disabled nodes fromfunctioning as hops for unicast messages between other nodes, asdescribed above, are possible. In one exemplary embodiment, eachrouting-disabled node is prevented from rebroadcasting route discoverymessages, although a routing-disabled node may reply to a routediscovery message if it is the destination for such message. Thus, ifroutes are discovered via the broadcast of route discovery messages, asdescribed above, then a routing-disabled node should not be identifiedas a hop in any route discovery message received by another node.Accordingly, the routing tables 231-235 are defined such that the routesindicated by such tables do not include a routing-disabled node as a hopfor messages unless the routing-disabled node is the destination. Inother words, the routing tables 231-235 are defined such that arouting-disabled node is indicated as the next hop only for messagesdestined for such routing-disabled node. Therefore, if therouting-disabled node transitions to a sleep state, such a transitionshould not disrupt the data paths for message destined for other nodes.

Note that there are various techniques that may be used to categorizenodes as routing or routing-disabled. In one exemplary embodiment, theconfiguration parameters 63 (FIG. 2) stored in a node includes anindicator, referred to hereafter as the “routing indicator,” indicatingwhether the node is a routing node or a routing-disabled node. As anexample, the routing indicator may be a one bit value in which a logicallow state indicates that the node is a routing node and a logical highstate indicates that the node is a routing-disabled node. Such anindicator may be user-controlled. For example, the indicator may be setto a default value (e.g., indicating that the node is a routing node),but this default value may be changed by a user. In at least oneexemplary embodiment described herein, one of the core functions 51 isfor changing the configuration parameters 63. Thus, a user may changethe routing indicator by initiating a remote procedure call for callingsuch core function 51. However, other techniques for setting and/orchanging the routing indicator are possible.

An exemplary use and operation of the network 20 will now be describedwith reference to FIG. 9.

In this regard, assume that the nodes 22 and 23 are both in range of thenode 24 such that they can each communicate directly with the node 24.Further assume that the node 21 broadcasts a route discovery message fordiscovering a route to the node 24. In addition, the routing table 232of the node 22 indicates a route to the node 24 in which the node 24 isidentified as the next hop, and the routing table 233 of the node 23similarly indicates a route of the node 24 in which the node 24 isidentified as the next hop. Also assume that the routing indicator ofthe node 22 is set to indicate that the node 22 is a routing-disablednode and the routing indicator of the node 23 is set to indicate thatthe node 23 is a routing node.

When the node 22 receives the route discovery message, the core logic 80of the node 22 checks the routing table 232 to determine whether itshould be updated, as shown by block 523 of FIG. 10. For example, if therouting table 232 does not indicate a route for the node 21 thatoriginally broadcast the route discovery message, then the core logic 80determines that the table 232 should be updated to indicate such aroute. In such an example, the core logic 80 of the node 22 updates therouting table 232, as shown by block 527, so that future messages can becommunicated to the node 21 without having to implement a routediscovery process.

The core logic 80 also determines whether the node 22 is the destinationfor the route discovery message and, therefore, whether to reply to theroute discovery message, as shown by block 529 of FIG. 10. In thisregard, the core logic 80 compares the destination address (i.e., theaddress of the node being sought) of the message to the address of thereceiving node 22. If the node 22 is the destination for the message,then the core logic 80 initiates a reply. Otherwise, the core logic 80decides not to reply. In the instant example, the node 22 is notidentified by the destination address of the route discovery message,and the core logic 80, therefore, makes a “no” determination in block529.

The core logic 80 of the node 22 also checks the routing indicatorstored at the node 22 to determine whether the node 22 is a routingnode, as shown by block 531 of FIG. 10. Such indicator indicates thatthe node 22 is a routing-disabled node. Thus, the core logic 80 discardsthe route discovery message without replying or rebroadcasting suchmessage, as shown by block 537.

When the node 23 receives the same route discovery message broadcast bythe node 21, the core logic 80 of the node 23 determines whether toupdate its routing table 233 and whether to reply, as described abovefor the node 22. In the instant example, the node 23 is not thedestination for the route discovery message and, therefore, does notreply. The core logic 80 of the node 23 also checks the routingindicator stored at the node 23 to determine whether the node 23 is arouting node, as shown by block 531 of FIG. 10. Such indicator indicatesthat the node 23 is a routing node. Thus, the core logic 80 determineswhether to rebroadcast the message, as shown by block 538 of FIG. 10. Inthis regard, the core logic 80 checks the hop addresses included in themessage. If the node 23 is identified by one such hop address, the corelogic 80 determines in block 538 that the message is not to berebroadcast. In the instant example, assume that the node 23 is notidentified by the route discovery message. Thus, the core logic 80initiates a rebroadcast of the route discovery message such that thenode 23 rebroadcasts the route discovery message, as shown by block 541.Before rebroadcasting the message, the core logic 80 inserts the addressof the node 23 as a hop address in the message. Therefore, if the node23 later receives a rebroadcast of this same message, the node 23 willnot attempt to rebroadcast the message again.

The route discovery message transmitted by the node 23 is received bythe node 24. The core logic 80 of the node 24 determines whether toupdate its routing table 234 and whether to reply, as described abovefor the node 22. In the instant case, the receiving node 24 isidentified by the destination address of the route discovery messagerebroadcast by and received from the node 23. Thus, the core logic 80 ofthe node 24 replies to the route discovery message, as shown by block549. In this regard, the node 24 replies with a unicast message that isrouted through the network 20 in reverse to the path used by the routediscovery message to reach the node 24. Based on the reply, the node 21updates its routing table 231 such that, when transmitting a message forthe destination node 24, the address of the node 23 is included in suchmessage as the next hop address. Accordingly, such message is routedfrom the node 21 through the node 23 to the node 24.

As illustrated in the above example, the routing-disabled node 22 isprevented from functioning as a hop for messages communicated from thenode 21 to the node 24. Such an effect is realized by preventing thenode 22 from participating in the route discovery process initiated bythe node 21 based on the routing indicator stored at the node 22. Thenode 22 is similarly disabled from participating in other routediscovery processes initiated by the node 21 or other nodes of thenetwork 20 unless the node 22 is the destination. In other examples,other techniques for disabling the node 22 from routing messages arepossible.

Network identifiers are preferably used to distinguish messagescommunicated by the network 20 from other messages communicated byforeign networks within range of the nodes 21-24. In this regard, thenetwork 20 is assigned a unique network identifier that distinguishesthe network 20 from other networks. Each node 21-24, 110 of the network20 is aware of and stores the network identifier. For example, thenetwork identifier may be one of the configuration parameters 63 (FIG.2) stored in the node. Further, for each message communicated within thenetwork 20, the transmitting node includes the network identifier of thenetwork 20. In this regard, each packet transmitted by the network 20has a header, which includes a network identifier field at the same bitpositions for each message. For example, the first byte of each headermay be the message's network identifier. For each message received bythe network communication device 77 of a receiving node of the network20, the core logic 80 of the receiving node compares the networkidentifier of the message to the stored network identifier for thenetwork 20. If the two identifiers match, then the receiving nodereceives and processes the message. However, if a matching identifier isnot found in the message, then core logic 80 determines that the messageis from a foreign network and discards the message without furtherprocessing it. Thus, each node responds to messages received by itsnetwork communication device 77 from other nodes of the network 20, andeach node discards messages received by its network communication device77 from other networks.

In one exemplary embodiment, a default network identifier is used forthe network 20. However, a user may change this default networkidentifier to a customized network identifier. For example, one of thecore functions 51 in each network node 21-24, 110 may be used to changethe network identifier used by the node. Thus, a user of the host 110 orother node may submit a remote procedure call that includes a newnetwork identifier for the network 20. Further, the user may transmitsuch a remote procedure call to each node 21-24 of the network 20 inorder to change the network identifier used by each such node 21-24. Inresponse to such a procedure call, the virtual machine 53 of thereceiving node calls and executes the core function 51 correlated withthe remote procedure call. Execution of such core function 51 overwritesthe current network identifier stored by the node with the new networkidentifier included in the remote procedure call. Thereafter, the nodeuses the new network identifier when transmitting and receiving messagesvia the network communication device 77.

Note that a similar procedure may be used to split a network 20 into twodifferent networks. In this regard, a user may submit the foregoingremote procedure call to only some of the nodes 21-24 of the network 20.Such nodes begin using the new network identifier while the other nodescontinue using the old network identifier. Accordingly, the network 20is effectively split into two smaller networks.

A problem may occur when a node 21-24, 110 is updated with an incorrectnetwork identifier. For example, when a user attempts to change thenetwork identifier of a node to a new network identifier, a remoteprocedure call may be used as described above. However, if the usermistypes or otherwise incorrectly defines the new network identifier,then the node may change the stored network identifier to an incorrectidentifier. In another example, transmission errors or data processingerrors may result in the node receiving and storing an incorrect networkidentifier. After a node begins using an incorrect network identifier,communication with the node may be difficult or, some cases, impossible.

For example, consider a case in which a user attempts to change thenetwork identifier of network 20 to a new address. Assume that the nodes21-23 are correctly updated with the new network identifier but thatnode 24 is updated with an incorrect identifier. In such a case, themessages communicated by the nodes 21-23 have one network identifier,referred to hereafter as the “correct network identifier,” and themessages transmitted by the node 24 have another network identifier,referred to hereafter as the “incorrect network identifier.” In such anexample, the nodes 21-23 do not recognize the messages transmitted bythe node 24, and the node 24 does not recognize the messages transmittedby the nodes 21-23. In this regard, the correct network identifier ofthe messages received by the node 24 from the nodes 21-23 does not matchthe incorrect network identifier being used by the node 24, and the node24, therefore, discards such messages. In addition, the incorrectnetwork identifier of the messages received by the nodes 21-23 from thenode 24 does not match the correct network identifier being used by thenodes 21-23, and the nodes 21-23, therefore, discard such messages.Thus, the node 24 can no longer communicate with the other nodes 21-23,and the node 24 appears to be “lost” from the network 20.

In one exemplary embodiment, each node stores and uses at least twonetwork identifiers such that the network 20 is identified by at leasttwo valid network identifiers. If a received message includes either ofthe network identifiers, then the receiving node processes and respondsto the message. Therefore, either of the network identifiers can be usedto route a message through the network 20. If one of the networkidentifiers for a node is incorrectly changed, then the node can stillbe reached via the other network identifier.

In one exemplary embodiment, one network identifier, referred to as the“primary network identifier,” is primarily used by the network nodes21-24, 110. Another network identifier, referred to as the “secondarynetwork identifier,” is used only for certain message types or incertain situations. For example, consider a case in which a userattempts to update the primary network identifier for each of the nodes21-24 but mistakenly updates the primary network identifier for the node24. In such a situation, the nodes 21-23 begin communicating using thecorrect primary identifier, and the node 24 begins communicating usingan incorrect primary identifier. Thus, communication with the node 24appears to be lost since the node 24 discards the messages from thenodes 21-23 and since the nodes 21-23 discard messages from the node 24,as described above.

In such a situation, a user of the host 110 may recognize that the node24 no longer appears to be present on the network 20. Thus, the user maytransmit a message, such as a remote procedure call, to the node 24using the secondary network address requesting the node 24 to return itsprimary network identifier. In response, the node 24 retrieves andreturns the incorrect primary network identifier, which is displayed bythe host 110. Upon viewing the incorrect primary network identifier, theuser may discover the problem that is preventing communication with thenode 24 via the correct primary network identifier. Thus, the user maysubmit a message, such as a remote procedure call, to the node 24 forchanging the primary network identifier to the correct identifier. Suchprocedure call is preferably transmitted using the secondary networkaddress such that the node 24 receives and responds to it. After thenode 24 updates its primary network address to the correct address,communication with the other nodes 21-23 via the primary network addressis enabled.

It is possible for the secondary network identifier to be changedsimilar to the techniques described above for the primary networkidentifier. However, in one exemplary embodiment, changes to thesecondary network identifier are disabled. For example, the secondarynetwork address may be stored in Read Only Memory (ROM). Such a featurehelps to prevent both network identifiers from being incorrectly updatedat the same time thereby helping to ensure that communication via atleast one of the network identifiers is always enabled. In otherembodiments, it is possible for the network 20 to be identified by anynumber of valid network identifiers.

In one exemplary embodiment, the routing tables 231-235 of the network20 are periodically purged in order to force rediscovery of the network20. Thus, if the topology of the network 20 has changed since discoveryof the routes indicated by the purged entries, more efficient routes maybe learned by the rediscovery. Note that all of the entries may beperiodically purged. Alternatively, the entries may be purged on anentry-by-entry basis based on the age of each entry. For example,periodically, a routing table may be purged of entries that have an ageabove a specified threshold. Various other techniques for purging therouting tables are possible in other examples.

An exemplary configuration of the node 24 will be described in moredetail hereafter in which the node 24 is configured to periodicallypurge its routing table 234. The other nodes 21-23 may be similarlyconfigured.

As shown by FIG. 11, the node 24 has a timer 612 that is configured totrack time based on a clock 615. In one exemplary embodiment, the timer612 is implemented in software and stored in the node's memory 55.However, the timer 612 may be implemented in hardware, software,firmware, or any combination thereof.

The configuration parameters 63 define a value, referred to hereafter asthe “purge threshold,” that is used to determine when to purge therouting table 234. In one exemplary embodiment, the timer 612 countstransitions of the clock 615 and compares the count to the purgethreshold. When the count exceeds the purge threshold, the timer 612generates an interrupt or otherwise informs the core logic 80. Afterinforming the core logic 80 that the purge threshold has been exceeded,the timer 612 resets and repeats the process of counting transitions ofthe clock 615 and informing the core logic 80 when the purge thresholdis exceeded.

When the purge threshold is exceeded, the core logic 80 purges theentries of the routing table 234. In one exemplary embodiment, the corelogic 80 purges all of the entries of the routing table 234 such thatthe purged table 234 does not indicate any routes within the network 20.In other embodiments, the entries may be purged based on variousfactors, such as age of the entries, for example. For illustrativepurposes, assume hereafter that the core logic 80 is configured to purgeall entries of the routing table 234.

Purging the routing table 234 forces the node 24 to perform a routerediscovery when a message is to be transmitted to any destinationpreviously indicated by a purged entry. For example, assume that therouting table 234 of the node 24 has an entry for the node 21. Suchentry indicates that for any message destined for the node 21, themessage should be transmitted to node 23, which routes the message tothe node 21. When the node 24 is ready to transmit a message to the node21, the node 24 uses such entry and includes the address of the node 23as the next hop for the message. However, when the entry is purged bythe core logic 80, the node 24 is forced to perform a route discoveryfor the node 21 the next time that the node 24 attempts to transmit amessage to the node 21.

In this regard, when the node 24 is ready to transmit a message to thenode 21 after purging of the routing table 234, the core logic 80searches the routing table 234 for an entry having a destination addressidentifying the node 21. However, after purging, such an entry does notexist. Thus, the core logic 80 initiates a route discovery process forthe node 24. An exemplary route discovery process is described above inwhich a route discovery message is transmitted when a node attempts todiscover a new route to a particular destination. Such a route discoveryprocess may be initiated by the node 24 to learn a data route. Inperforming such a route discovery, a new data route more efficient thanthe one previously indicated by the routing table 234 prior to thepurging by the core logic 80 may be discovered. For example, a dataroute passing through fewer numbers of hops may be discovered afterpurging by the core logic 80.

In one exemplary embodiment, purging of the routing table 234 can beselectively disabled by a user. In this regard, the routing thresholdcan be established and/or updated by a user. For example, one of thecore functions 51 may be used to change the routing threshold. In suchan embodiment, a user may change the routing threshold by initiating amessage, such as a remote procedure call, for calling such core function51. The procedure call may include a new value for the routingthreshold, which is defined by the user. The foregoing core function 51may change the routing threshold to the new value when called. Thus,initiating the remote procedure call changes the routing threshold tothe new value. However, other techniques for setting and/or changing therouting threshold are possible.

The user may lengthen the time between purging of the routing table 234by increasing the routing threshold, and the user may shorten the timebetween purging of the routing table 234 by decreasing the routingthreshold. In one exemplary embodiment, the timer 612 determines whetherthe count is equal to the threshold. If so, the timer 612 informs thecore logic 80 that a purging of the routing table 234 is to beperformed. However, if the routing threshold is set to a value of zeroor less, then the count never equals the routing threshold unless therouting threshold is later updated to a value greater than zero. Thus,setting the routing threshold to a value of zero or less effectivelydisables purging of the routing table 234. In other embodiments, othertechniques for disabling the purging of the routing table 234 arepossible.

Disabling purging of a routing table can be beneficial for a variety ofreasons. For example, if the nodes 21-24 of the network 20 are likely tobe stationary, then it is unlikely that more efficient data routes canbe learned by forcing a route rediscovery. In such a situation, thebenefits of route rediscovery may be outweighed by the additionalmessaging, such as the communication of route discovery messages andresponses thereto, caused by such rediscovery. Other reasons fordisabling purging of a routing table are possible.

Note that the host 110 or other node of the network 20 can be used toview and/or change any of the configuration parameters 63, including therouting threshold and routing indicator described above. In this regard,as described above, a user may view various information about a node byselecting the node in window 307 (FIG. 6). In one exemplary embodiment,the user may provide an input, such as selection of a tool bar option ora menu option, for requesting a display of the configuration parameters63 (FIG. 2) for a selected node. In response to such input, the corelogic 152 of the host 110 transmits one or more remote procedure callsfor retrieving the configuration parameters 63 of the selected node.When the selected node receives such a remote procedure call, thevirtual machine 53 of the node calls a core function 51, which retrievesone or more configuration parameters 63 and returns the retrievedparameters 63 to the host 110, which then displays them to the user. Inone exemplary embodiment, all of the configuration parameters arereturned in response to a single remote procedure call. In anotherembodiment, each remote procedure call specifies a subset (at least one)of the configuration parameters such that multiple remote procedurecalls are used if all of the configuration parameters 63 are to bereturned. If desired, the user may specify which of the configurationparameters 63 of the selected node are to be returned.

The user can view and, if desired, change any of the configurationparameters 63 retrieved from the selected node and displayed by the host110. If a configuration parameter 63 is changed by user input, the corelogic 152 of the host 110 is configured to transmit a remote procedurecall for changing the parameter. Such call identifies the changedconfiguration parameter 63 and includes the new value for the changedconfiguration parameter 63. The remote procedure call is received by theselected node. In response to the remote procedure call, the virtualmachine 53 of the selected node calls a core function 51, which updatesthe stored configuration parameters 63 based on the configurationparameter value or values in the remote procedure call. Any of theconfiguration parameters 63 may be updated in such manner. In addition,other techniques for updating the configuration parameters 63 arepossible. For example, the aforementioned core function 51 for updatingone or more configuration parameters 63 may be called by a function callin the script image 52 rather than by a remote procedure call.

Several of the embodiments have been described herein in the context ofwireless sensor networks. It should be emphasized that the communicationand networking techniques described herein may be applied to other typesof networks.

1. A network node for use in a wireless sensor network, comprising:memory configured to store a routing indicator indicating whether thenetwork node may function as a routing node for messages destined forother nodes of the wireless sensor network; and logic configured tocontrol, based on the routing indicator, whether the network node isspecified as a hop for a data path from a source node to a destinationnode of the wireless sensor network.
 2. The network node of claim 1,wherein the logic is configured to check the routing indicator inresponse to a route discovery message received by the network node, andwherein the logic is configured to respond to the route discoverymessage based on the routing indicator.
 3. The network node of claim 2,wherein the logic is configured to respond to the route discoverymessage such that the network node is listed as a hop in a routing tableof another node of the wireless sensor network if the routing indicatorindicates that the network node may function as a routing node.
 4. Thenetwork node of claim 1, wherein the network node is configuredtransition to a sleep state at least once while other nodes of thewireless sensor network are communicating through the wireless sensornetwork, and wherein the network node is unable to communicate withother nodes of the wireless sensor network while in the sleep state. 5.The network node of claim 3, wherein the wireless sensor network is amesh network.
 6. A wireless sensor network, comprising: a plurality ofnodes, each of the nodes configured to communicate messages through thewireless sensor network, at least one of the nodes disabled fromfunctioning as a routing node based on a routing indicator of the onenode.
 7. The wireless sensor network of claim 6, wherein the one node isconfigured to check the routing indicator in response to a routediscovery message received by the one node.
 8. The wireless sensornetwork of claim 7, wherein the one node is configured to refrain fromresponding to the route discovery message based on the routingindicator.
 9. The network node of claim 6, wherein the one node isconfigured transition to a sleep state at least once while other nodesof the wireless sensor network are communicating through the wirelesssensor network, and wherein the one node is unable to communicate withother nodes of the wireless sensor network while in the sleep state. 10.The network node of claim 8, wherein the wireless sensor network is amesh network.
 11. A method for controlling data paths for wirelesssensor networks, comprising the steps of: disabling a first node of awireless sensor network from functioning as a routing node within thewireless sensor network; performing a route discovery within thewireless sensor network; and defining data routes, based on the routediscovery, for messages to be communicated through the wireless sensornetwork, wherein the data routes are defined, based on the disablingstep, such that the first node is prevented from being a hop formessages destined for other nodes.
 12. The method of claim 10, whereinthe disabling step comprises the step of controlling a routing indicatorof the first node.
 13. The method of claim 12, further comprising thesteps of: receiving a route discovery message at the first node; andchecking the routing indicator in response to the route discoverymessage.
 14. The method of claim 10, further comprising the step ofenabling the first node to transition to a sleep state, wherein thedisabling step is based on the enabling step.
 15. The method of claim10, wherein the disabling step is based on a geographic location of thefirst node.
 16. The method of claim 10, wherein the disabling step isbased on sleeping characteristics of the first node.
 17. The method ofclaim 15, wherein the wireless sensor network is a mesh network.